The present invention relates generally to computer operating systems. More particularly, the present invention relates to a technique for transfer of control and parameter manipulation between computer system protection domains.
A computer operating system is the software in a computer system that performs three basic functions. First, it manages the resources of the computer system and allows such resources to be shared among multiple users. For example, several applications may reside in memory, but only one application may be executing on the CPU at any given time. Another example is a single printer that is shared among multiple applications. Second, the operating system protects the applications executing on the system from corruption, for example from other concurrently executing applications. As an illustration, the operating system protects the memory space of an application and will not allow another errant application to corrupt the memory space. Third, the operating system provides an abstraction layer on top of the hardware of the computer system thus allowing access to the lower level hardware resources using higher level abstractions. For example, a physical disk drive allows data to be stored on the drive, but there is no intrinsic organization to that data. An operating system file system provides an abstraction layer between the physical disk drive and applications thus providing an organized file system.
Computer processors generally have two modes of operation, a privileged mode and a user mode. These modes are implemented at the hardware level of the processor. The privileged mode allows execution of all processor instructions, giving complete access to the hardware. Operating system software generally executes in privileged mode. The user mode is the mode in which most user applications execute. The instructions that can be performed while in user mode are restricted by the hardware of the system. Executing in user mode ensures that user applications cannot execute instructions that will interfere with the operating system or other user applications.
In the following description, user application programs that request services from the operating system are referred to as xe2x80x9cclient applicationsxe2x80x9d.
Most operating systems are structured as either monolithic or micro-kernel. A monolithic operating system is an operating system in which most of the operating system functions and services are resident in the operating system kernel. The kernel is the portion of the operating system which provides the basic operating system functionality. The software in the kernel is loaded into memory during initialization of the system. Kernel software typically executes in privileged mode. In a monolithic operating system a client application invokes an operating system function by executing a processor instruction which switches to privileged mode and then jumps to the particular location within the operating system kernel at which the code for the function resides. The client application may pass parameters to the operating system through the system stack.
A micro-kernel operating system, as its name implies, contains less operating system functionality in the operating system kernel. Many of the operating system functions are implemented through user mode applications, called servers. A client application invokes an operating system function by loading the stack with the desired server identification and any parameters to be passed to the server, and then calling a library routine which places the stack information into a generalized message format. The function of taking information from the stack and formatting it into a generalized message format is called message marshaling. The client application then calls a function in the operating system kernel which determines the correct server based on the server identification, passes the marshaled message to the server, and transfers control to the server. The server un-marshals the message to retrieve the parameters and performs some function. The message format is highly generalized, and the same format is used for invoking various operating system functions.
One benefit of a micro-kernel operating system is its flexibility. Servers may be changed and modified without changing the operating system kernel, and client applications can choose between multiple servers providing the same or similar services. In some implementations, the servers may be located on a different physical machine than the client application, and the communication between client applications and servers is achieved via messages sent on a network.
One problem with micro-kernel operating systems is that the context switch which results when a client application invokes an operating system function is often slow. As described above, parameter passing from the client application to the server requires message marshaling and un-marshaling. In addition, the server must check the parameters prior to performing the service in order to confirm that the parameters are in the correct format and that they are within allowed boundaries. Both of these parameter related functions take time and slow down the context switch. In addition, there is demultiplexing overhead. Since client applications invoke servers using a generalized request format which includes an identification of the server requested, the operating system must demultiplex the request to determine what server the client application is requesting. It is noted that these message marshaling, parameter checking, and demultiplexing functions must be performed each time a client application requests an operating system service by invoking a server.
Some of these performance problems have been solved through the use of portals, which provide for the transfer of control between computer system domains. The use of portals is described in D. Probert and J. Bruno, Building Fundamentally Extensible Application-Specific Operating Systems in SPACE, UCSB Computer Sciencexe2x80x94TRCS95-06, Mar., 1995; D. Probert and J. Bruno, Efficient Cross-domain Mechanisms for Building Kernel-less Operating Systems, Technical Report TRCS96-06, University of California, Santa Barbara, May 1996; and A. Beitch and N. Hutchinson, Keaxe2x80x94A Dynamically Extensible and Configurable Operating System Kernel, Proceedings of the Third Conference on Configurable Distributed Systems (ICCDS) 1996. A similar construct, called a door, for providing transfer of control between computer system domains is described in J. Mitchell, J. Gibbons, G. Hamilton, P. Kessler, Y. Khalidi, P. Kougiouris, P. Madany, M. Nelson, M. Powell, and S. Radia, An Overview of the Spring System, Proceedings of Compcon Spring 1994, February 1994, pp. 122xe2x80x94131.
Generally, as described in the above cited references, portals and doors are software mechanisms which, when executed, manage the transfer of control of program execution between two computer system domains. Portals will be described in further detail in the detailed description.
The present invention provides novel parameter manipulation and portal management techniques for use in conjunction with the transfer of control between computer system protection domains using portals. A protection domain, as will be described in further detail below, defines an execution environment within the computer system.
In accordance with one embodiment of the invention, portal invocation results in the insertion of a value, which is a function of the state of the computer system, in a parameter list which is passed between protection domains. Thus, when parameters are passed during the transfer of control between computer system protection domains, a portal in accordance with the invention will insert an additional value which is computed as a function of the state of the computer system into the parameter list. While the above referenced prior art portal techniques include the insertion of constants into parameter lists, such prior art techniques do not include the insertion of a value which is computed as a function of the state of the computer system. For example, an identification of the invoking protection domain, or the current date/time, may be inserted into the parameter list.
In accordance with another embodiment of the invention, portal invocation results in the execution of a segment of portal code which was supplied by an operating system server. Thus, a first server may supply code to a portal, where the supplied code defines the parameter manipulation to be performed when a second server is invoked through use of the portal. This technique may be used, for example, to establish a shared memory window between two protection domains. The first and second servers may be the same or different servers.
In accordance with particular embodiments of the invention, system portals are managed by a portal manager. The portal manager handles the registration and instantiation of portals for use by client applications. The portal manager instantiates a portal by dynamically generating portal code at the request of a client application.
In accordance with yet other embodiments of the invention, portals are used to improve the performance of file processing and to provide for compatible parameter manipulation during a sequence of portal invocations.
These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings.